Skip to content

Add radio button rendering for enum Dag Params - #71180

Open
fat-catTW wants to merge 1 commit into
apache:mainfrom
fat-catTW:issue-56632-param-enum-ui
Open

Add radio button rendering for enum Dag Params#71180
fat-catTW wants to merge 1 commit into
apache:mainfrom
fat-catTW:issue-56632-param-enum-ui

Conversation

@fat-catTW

@fat-catTW fat-catTW commented Aug 5, 2026

Copy link
Copy Markdown
Contributor

Why

Dag authors currently cannot choose a radio button UI for enum Params in the Trigger Dag form. This makes small, fixed choice sets less convenient, especially when the choices are generated from deployment-local configuration such as an INI file.

Solution

Add an opt-in x-airflow-ui.widget = "radio" schema hint for enum Params. Enum Params continue to render as dropdowns by default, while Params with the radio widget hint render as radio buttons.

The Params documentation and tutorial Dag also show how to generate enum choices from a colocated INI file at Dag parse time, so the Trigger Dag form uses serialized Dag Params instead of calling a dynamic choice provider.

Helps address #56632.

Screenshot

Trigger Dag form showing an enum Param rendered as radio buttons:

螢幕擷取畫面 2026-08-05 230724
Was generative AI tooling used to co-author this PR?
  • [X] Yes (please specify the tool below)

Generated-by: [Codex] following the guidelines


  • Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
  • For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
  • When adding dependency, check compliance with the ASF 3rd Party License Policy.
  • For significant user-facing changes create newsfragment: {pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.

@fat-catTW
fat-catTW force-pushed the issue-56632-param-enum-ui branch from cbebad7 to fc31540 Compare August 5, 2026 15:20

@bbovenzi bbovenzi left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm wary of adding a new x-airflow-ui option to declaring params. First the name isn't great. Second, we should define how we plan to expand this in the future.

Second, I am not sure if this closes the old issue because the person asked for a selector or a radio over plain text. I don't think it matters as much which of the two exist.

Third, the radio has no option to unselect when it is an optional param.

@fat-catTW
fat-catTW force-pushed the issue-56632-param-enum-ui branch 2 times, most recently from cfb5629 to fc31540 Compare August 6, 2026 05:11
@fat-catTW

Copy link
Copy Markdown
Contributor Author

Good afternoon.
Thanks for the review. I agree with the concerns here.

To clarify the current state of this PR:
The example demonstrates that a Dag author can read an INI file at Dag parse time, filter the available interfaces, and pass those values into a Param enum. Airflow Params currently expect the enum choices to be materialized when the Dag is parsed; the trigger form reads the serialized Param schema and does not have a generic "choices source" mechanism that can load/filter options when the form opens.

The trigger form already renders enum values as choices via the existing dropdown support, and this PR experiments with rendering the same enum values as radio buttons via x-airflow-ui. So this covers the “do not require free-text input” part, but it does not introduce a general dynamic choices provider or a reusable config-source mechanism.

I also agree that the selector vs radio part is secondary. The main missing design question is how Airflow should expose UI presentation preferences for Params in a way that can be extended later. The current x-airflow-ui key may be too ad hoc without that broader shape being defined.

Given that, I think there are two possible directions:

  1. Keep this PR smaller and use the existing enum dropdown behavior, documenting the INI-at-parse-time pattern without adding a new UI extension key.
  2. Expand this PR into a more deliberate Param UI presentation API, including how widgets such as dropdown/radio would be selected and how optional radio Params can be cleared.

I’m happy to take either direction. If maintainers think this PR should define the broader UI extension shape, I can work on that here; otherwise I can reduce this PR to the existing enum dropdown/docs pattern.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area:UI Related to UI/UX. For Frontend Developers. kind:documentation

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants